\pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\f0\b0\i0\ulnone\fs28\fc0\cf0 Q: I created a
\fc1\cf1 pop-up list
\fc0\cf0 by dragging it from the InterfaceBuilder palette into a window, but it doesn't seem to be freed when the window is freed. \
\
A: This is a bug. Freeing a
\fc1\cf1 window
\fc0\cf0
\i does
\i0 free all of its views, but the
\fc1\cf1 pop-up list
\fc0\cf0 is not a member of the view
\fc1\cf1 hierarchy
\fc0\cf0 ! It's attached as the target of a Button. There are two situations in which this bug can bite an unwary programmer:\
\
\fi-980\li980 1) An application creates multiple document windows by loading a nib section multiple times. In the nib section, there's a
\fc1\cf1 window
\fc0\cf0 containing a
\fc1\cf1 pop-up list. The application leaks a pop-up list instance and a DPS window each time a document is closed. Furthermore, MallocDebug's "Leaks" button won't find the missing nodes because a pop-up list is a window
\fc0\cf0 , and there are pointers to the missing
\fc1\cf1 pop-up lists in [NXApp windowList].\
\
2) Same situation as in (1), except that each time, the nib section is loaded into a unique zone, and the zones are destroyed when the documents are closed. Destroying the zone gets rid of all the garbage, but now there are bad pointers in [NXApp windowList]. Some time later, the application crashes in code that you didn't write, referencing objects that you don't know about, leaving you very confused.\
\fi0\li0 \
The solution is to free the pop-up list when you free the window. When setting up the nib file, make an outlet to the Button. In your code, use the outlet to ask the Button for its target before you free the window. The target is the pop-up list, which you then free explicitly.\
